Blog

Brad Wood

March 02, 2017

Spread the word


Share your thoughts

There's a lot of command tools out there written by developers to help them automate all sorts of tasks from code refactoring, linting, and builds. Node has become a popular tool to write reusable tools that can be run from the command line, but many CF developers don't realize that CommandBox has allowed developers to do this nativley in CFML for years now.

CLI Goodness

Writing a CLI tool sounds a little scary, but it's actually very easy-- as easy as a CFC containing a single method. Let's take a look at a real CLI command that you can run on CommandBox:

/commands/hello.cfc

component {
    function run(){
        return 'Hello World!'; 
    }
}

Hey, that's not so bad is it? By convention, the name of your command will be the same as the CFC name (hello) which means you'd run the above like so from any operating system:

$> box hello
Hello World!

Now you can add this command to Jenkins builds, package scripts, cron jobs, cfexecute, or just from your local bash shell!

Interactivity

But there's more you can do. A lot more. I'm a little biased, but I honestly think CommandBox is better than Node in several of these areas. Check out this cool stuff you can add into your new command line tools:

  1. Nest commands into names spaces like coldbox create app, coldbox create module, etc
  2. Accept named or positional parameters with no manual parsing or additonal libs needed.
  3. Users are automatically prompted for missing required params
  4. Easy boolean flags out-of-the-box like --force
  5. Super-easy ANSI formatting like font colors and decoration like print.blueText( 'sad panda' )
  6. Bullt-in tab completion for your command names and parameter name/values
  7. Automatic help screens generated right from your CFC's metadata
  8. Complete interactivity with your users via helper methods like ask(), confirm(), and waitForKey()
  9. Automatically send back proper exit codes to the OS when an error happens
  10. Nice helpers for finding current working directory, expanding relative paths, and getting terminal size
  11. Even access a database via on-the-fly JDBC connections.

Where do I start?

Want to play around with all this? 100% of what I mentioned above is documented right here in our docs: https://ortus.gitbooks.io/commandbox-documentation/content/developing/commands/developing_commands.html

That page will walk you through creating your first command in only a few minutes. And when you're ready to share your work with the world, just stick it in a GitHub repo and use the publish command to send it up to ForgeBox. Setting up some package scripts will even help manage all your versions. When I want to make changes to a command live, I just have to type this and my package scripts take care of tagging the repo, pushing to GitHub, and publishing the latest version to ForgeBox!

CommandBox> bump --minor

https://ortus.gitbooks.io/commandbox-documentation/content/packages/creating_packages/creating_packages.html

Examples

Some people like to learn from checking out existing projects. Feast your eyes on these example CommandBox modules that have custom commands in them:

Any of those projects above can be installed globally into your local CommandBox installation just like this:

CommandBox> install commandbox-chuck-norris

Get going

OK, you have the tools. You're a CF dev and it's time you put some of your totally aweseome ideas into action. Go and create some sweet stuff, then show your friends and watch their suprise when you tell them your new CLI tooling is written in ColdFusion!

Add Your Comment

(5)

Mar 02, 2017 17:46:09 UTC

by Adam Cameron

Interesting stuff. Given you mention it, it'd be good if you could actually objectively (or, hey, even subjectively!) quantify how "CommandBox is better than Node in sevearl of these areas".

Mar 02, 2017 18:25:51 UTC

by Luis Majano

Thanks for your comment Adam! I am sure that would be a cool blog entry to do separately so as to distinguish our differences or do a compare-contrast objectively. Inherently, there are architectural and language differences, so we cannot compare apples to apples in many areas. However, there are many areas we can do this and we have improved upon NPM and Node CLI as well. We had the pleasure of analysing how these tools work and be able to take the best out of them and port what we thought would be best over to CommandBox. Off the bat our caching strategy for artifacts is part of CommandBox which does not exist in NPM, which makes CommandBox package resolving and installation way faster and better performant. I'll let Brad comment (While I go get some popcorn)

Mar 02, 2017 20:03:37 UTC

by Adam Cameron

G'day Luis. I reckon of the article was just "commandbox is good, and you can do this", then it's fair cop to not justify one's self. But an article which makes a point of saying x is better than y, then it's *slightly* disingenuous to just say it rather than actually explaining / showing how x is actually better than y. This kinda reads more like an advert than exposition. But I guess advertising *box stuff *is* Brad's raison d'etre ;-) That said: it's a good teaser for commandbox commands. And I look fwd to reading a more meaningful comparison. Cheers!

Mar 02, 2017 20:05:00 UTC

by Adam Cameron

PS: your comments system are swallowing paragraph breaks. My previous comment wasn't one run-on thought, it was three paras. Maybe you need a FormatBox or something ;-)

Mar 03, 2017 01:55:30 UTC

by Brad Wood

Hi Adam, that's a fair question to ask. I've expounded on the way I think CommandBox is better than npm at creating CLI tools, but I did so on my personal blog as to not clutter the comments here. http://www.codersrevolution.com/blog/why-writing-cli-scripts-in-commandbox-is-better-than-node

Recent Entries

Partner with BoxLang and Ortus at Into the Box 2025: Empowering the Future of Modern Software Development!

Partner with BoxLang and Ortus at Into the Box 2025: Empowering the Future of Modern Software Development!

At Ortus Solutions, we’ve always been at the forefront of innovation in the ColdFusion ecosystem. From pioneering modern ColdFusion practices to developing cutting-edge tools and frameworks, we’ve been passionate to help and sup[port the community into shaping the future of web development.That’s why we decided to build BoxLang, our new JVM programming language that not only builds on the strengths of ColdFusion but takes modern software development to the next level.

Maria Jose Herrera
Maria Jose Herrera
December 23, 2024
Why BoxLang When You Have Kotlin, Groovy, Scala, and more…

Why BoxLang When You Have Kotlin, Groovy, Scala, and more…

As we approach a stable release of BoxLang and our continued marketing reaches more folks, many have asked about its purpose. Why create a new language when the JVM ecosystem already includes established languages like Kotlin, Groovy, and Scala, to name a few.

Luis Majano
Luis Majano
December 18, 2024